<Este archivo debe contener todo lo necesario para instalarse y todas las variables de entorno que necesite, sumado a esto se pueden agregar comentarios relevantes>

!!! modificar path de archivos de salida
!!! modificar path de archivos maestros
!!! modificar path de archivos de beneficiarios

* Todas las decisiones de diseño se realizaron considerando que este es un comando de reporte por lo que consideramos que en primer lugar debe ser amigable y en segundo lugar debe asegurarse de que el usuario realmente exprese mediante los parámetros lo que realmente desea hacer, en caso de duda, se cancela el reporte y se informa.

* Una entrada como la que se desprende en primera instancia del enunciado tiene severas dualidades. Dicha entrada sería de la forma ./plist opciones filtros archivos.
  Esto sumado a la necesidad del comodin asterisco (*) produce las siguientes situaciones:
    - En caso de NO indicar filtros por beneficio o agencia NO se puede disernir que tipo de filtro es. Ej: ./plist opciones 1 2 3 benef.1111
      Podria suponer que primero van los filtros de beneficios y luegos los de agencia, o viceversa sin embargo bien podrian ser 1,2 y 3 o 1 y 2,3 o bien 1,2,3 y sin
      filtros, se solucionaría la segunda parte pidiendo siempre la presencia de los dos tipos de filtros, pero sigo teniendo el primer problema.
      El primer inconveniente se resolvería indicando códigos de agencias y beneficios en vez de ids, ya q uno tiene 5 chars y el otro 6 y podría disernirlos, pero esos códigos meramente aleatorios, y considero que el ID es muchísimo más amigable a usuario. Recordemos que es un comando de reporte, es extremadamente
      valorado que sea amigable.
    - Por el mismo requisito autoimpuesto de ser amigable al usuario, un filtro o archivo inexistente finaliza la ejecución del comando sin reportar por lo que la interpretación del comodín la debe resolver el script y no el bash. Por esto se agregan 3 opciones para indicar q tipo de filtros y archivo desea indicar el usuario, además se pide explicitamente que estén agrupados por comillas, que a la vez protege al comando del la expansion del bash. Notar que la expansión del bash para * produciría el NO reporte siempre que exista un archivo que no sea de beneficios en la ruta, además de que implicaría al usuario indicar la ruta, etc.

Por todas estas razones y algunas mas se decide pasar todos los parametros por medio de opciones y es el perl script el que se encarga de interpretarlas, validarlas, etc.
  Los archivos de beneficiarios se indican mediante la opción -f, de files, y se agrupan entre comillas dobles. Ej: ./plist.pl -f "benef.1111 benef.123"
  Los filtros de agencias se indican mediante la opción -a, de agencies, y se agrupan los IDS de la misma manera. Ej: ./plist.pl -f "benef.1" -a "1 2 3 4"
  Los filtros de beneficios se indican mediante la opción -b, de benefits, y se agrupan los IDS de la misma manera. Ej: ./plist.pl -f "benef.1" -b "1 2 3 4"
  Para el filtro por estado el comportamiento es el mismo pero puede reaizarse sin agrupar por comillas. Eh: ./plist.pl -f "benef.1" -c -earp
  En caso de precisar comodines: -b "*" o -a "*" y -f "benef.1*".
  En caso de -f, beneficiarios, dentro se invoca a ls, usando la expansión del bash, excepto que sea -b "*", que se resuelve similarmete pero modificando la llamada a ls.

* En cuanto a la salida por archivo algunas consideraciones:
    - Para la salida por archivo, option -d, se redirecciona STDOUT por lo que ambas tienen el mismo formato. Habría que analizar si realmente es conveniente que el formato de salida del archivo no sea mediante printf con espaciado de relleno, en vez de indicar un separador. Claramente la diyuntiva radica en la facilidad de lectura y la facilidad de operarlo con comandos como grep, cut, etc.

* Se utilizan variables globales para algunas variables y flags configurables por el comando que ejectuta el usuario. Así como también los contenedores de filtros.

* Para el filtrado se utilizan hashes donde las claves son los valores válidos del filtro. Se toma el campo en el registro actual y se busca su valor en dicho hash. Si existe
  pasa el filtro, en caso contrario no.

* Para el contenedor de registros ya filtrados a reportar se utiliza un array, más que nada porque no se realizan busquedas en el mismo, solo se lo carga y se lo recorre 
  secuencialmente.

* Para la matriz de control se utiliza un hash con clave concatendada a los valores. La matriz es filas provincias y columnas beneficios, por lo que la clave es provincia.separador.beneficio.
  Luego se procede a aumentar en uno el valor asociado a la clave. Obviamente en caso de que la clave no exista, se la crea automaticamente con valor uno. A la par de esto se mantiene
  un hash de provincias y otro de beneficios con el motivo de poder armar la matriz
  El proceso es el siguiente: Se recorre en un doble ciclo provincias primero y dentro beneficios, se rearma la clave y se toma el valor del hash. En caso de no existir, obviamente
  el valor de dicha celda es cero (0).

* El proceso de validacion por etapas. Se recuerda que por ser un comando de reporte, se considero apropiado que ante cualquier error NO se realice el reporte, ya que puede ser un error
  del usuario al ingresar parametros que desenboque en un reporte que dicho usuario considere correcto cuando no lo es. En primera instancia se verifican opciones incompatibles, 
  así como ser -e sin -c. Luego se verifica el formato de las parametros de las opciones, como ser que los parámetros de -f inicien con "benef." o los parámetros de -b y -a sean
  numéricos (los IDs). En última etapa se verifica el valor de dichos parámetros. 
  Todas estás validaciones setean variables gloales de error como ser $ERROR_STATUS y $ERROR_MSG. Luego de que puedan haber sido modificadas se chequea su valor y en caso de indicar
  error se finaliza la ejecucíon informando dicho error.
